home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1017.txt < prev    next >
Text File  |  1994-08-01  |  48KB  |  1,067 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                    Barry M. Leiner
  8. Request for Comments: 1017                                         RIACS
  9.                                                              August 1987
  10.  
  11.               Network Requirements for Scientific Research
  12.  
  13.               Internet Task Force on Scientific Computing
  14.  
  15. STATUS OF THIS MEMO
  16.  
  17.    This RFC identifies the requirements on communication networks for
  18.    supporting scientific research.  It proposes some specific areas for
  19.    near term work, as well as some long term goals.  This is an "idea"
  20.    paper and discussion is strongly encouraged.  Distribution of this
  21.    memo is unlimited.
  22.  
  23. INTRODUCTION
  24.  
  25.    Computer networks are critical to scientific research.  They are
  26.    currently being used by portions of the scientific community to
  27.    support access to remote resources (such as supercomputers and data
  28.    at collaborator's sites) and collaborative work through such
  29.    facilities as electronic mail and shared databases.  There is
  30.    considerable movement in the direction of providing these
  31.    capabilities to the broad scientific community in a unified manner,
  32.    as evidence by this workshop. In the future, these capabilities will
  33.    even be required in space, as the Space Station becomes a reality as
  34.    a scientific research resource.
  35.  
  36.    The purpose of this paper is to identify the range of requirements
  37.    for networks that are to support scientific research.  These
  38.    requirements include the basic connectivity provided by the links and
  39.    switches of the network through the basic network functions to the
  40.    user services that need to be provided to allow effective use of the
  41.    interconnected network.  The paper has four sections.  The first
  42.    section discusses the functions a user requires of a network.  The
  43.    second section discusses the requirements for the underlying link and
  44.    node infrastructure while the third proposes a set of specifications
  45.    to achieve the functions on an end-to-end basis.  The fourth section
  46.    discusses a number of network-oriented user services that are needed
  47.    in addition to the network itself.  In each section, the discussion
  48.    is broken into two categories.  The first addresses near term
  49.    requirements: those capabilities and functions that are needed today
  50.    and for which technology is available to perform the function.  The
  51.    second category concerns long term goals: those capabilities for
  52.    which additional research is needed.
  53.  
  54.    This RFC was produced by the IAB Task force a Scientific Computing,
  55.  
  56.  
  57.  
  58. Leiner                                                          [Page 1]
  59.  
  60. RFC 1017          Requirements for Scientific Research       August 1987
  61.  
  62.  
  63.    which is chartered to investigate advanced networking requirements
  64.    that result from scientific applications.  Work reported herein was
  65.    supported in part by Cooperative Agreement NCC 2-387 from the
  66.    National Aeronautics and Space Administration (NASA) to the
  67.    Universities Space Research Association (USRA).
  68.  
  69. 1.  NETWORK FUNCTIONS
  70.  
  71.    This section addresses the functions and capabilities that networks
  72.    and particularly internetworks should be expected to support in the
  73.    near term future.
  74.  
  75. Near Term Requirements
  76.  
  77.    There are many functions that are currently available to subsets of
  78.    the user community.  These functions should be made available to the
  79.    broad scientific community.
  80.  
  81. User/Resource Connectivity
  82.  
  83.    Undoubtedly the first order of business in networking is to provide
  84.    interconnectivity of users and the resources they need.  The goal in
  85.    the near term for internetworking should be to extend the
  86.    connectivity as widely as possible, i.e. to provide ubiquitous
  87.    connectivity among users and between users and resources.  Note that
  88.    the existence of a network path between sites does not necessarily
  89.    imply interoperability between communities and or resources using
  90.    non-compatible protocol suites.  However, a minimal set of functions
  91.    should be provided across the entire user community, independent of
  92.    the protocol suite being used.  These typically include electronic
  93.    mail at a minimum, file transfer and remote login capabilities must
  94.    also be provided.
  95.  
  96. Home Usage
  97.  
  98.    One condition that could enhance current scientific computing would
  99.    be to extend to the home the same level of network support that the
  100.    scientist has available in his office environment.  As network access
  101.    becomes increasingly widespread, the extension to the home will allow
  102.    the user to continue his computing at home without dramatic changes
  103.    in his work habits, based on limited access.
  104.  
  105. Charging
  106.  
  107.    The scientific user should not have to worry about the costs of data
  108.    communications any more than he worries about voice communications
  109.    (his office telephone), so that data communications becomes an
  110.    integral and low-cost part of our national infrastructure.  This
  111.  
  112.  
  113.  
  114. Leiner                                                          [Page 2]
  115.  
  116. RFC 1017          Requirements for Scientific Research       August 1987
  117.  
  118.  
  119.    implies that charges for network services must NOT be volume
  120.    sensitive and must NOT be charged back to the individual.  Either of
  121.    these conditions forces the user to consider network resources as
  122.    scarce and therefore requiring his individual attention to conserve
  123.    them.  Such attention to extraneous details not only detracts from
  124.    the research, but fundamentally impacts the use and benefit that
  125.    networking is intended to supply.  This does not require that
  126.    networking usage is free.  It should be either be low enough cost
  127.    that the individual does not have to be accountable for "normal"
  128.    usage or managed in such a manner that the individual does not have
  129.    to be concerned with it on a daily basis.
  130.  
  131. Applications
  132.  
  133.    Most applications, in the near term, which must be supported in an
  134.    internetwork environment are essentially extensions of current ones.
  135.    Particularly:
  136.  
  137.       Electronic Mail
  138.  
  139.          Electronic mail will increase in value as the extended
  140.          interconnectivity provided by internetworking provides a much
  141.          greater reachability of users.
  142.  
  143.       Multimedia Mail
  144.  
  145.          An enhancement to text based mail which includes capabilities
  146.          such as figures, diagrams, graphs, and digitized voice.
  147.  
  148.       Multimedia Conferencing
  149.  
  150.          Network conferencing is communication among multiple people
  151.          simultaneously.  Conferencing may or may not be done in "real
  152.          time", that is all participants may not be required to be on-
  153.          line at the same time.  The multimedia supported may include
  154.          text, voice, video, graphics, and possibly other capabilities.
  155.  
  156.       File Transfer
  157.  
  158.          The ability to transfer data files.
  159.  
  160.       Bulk Transfer
  161.  
  162.          The ability to stream large quantities of data.
  163.  
  164.       Interactive Remote Login
  165.  
  166.          The ability to perform remote terminal connections to hosts.
  167.  
  168.  
  169.  
  170. Leiner                                                          [Page 3]
  171.  
  172. RFC 1017          Requirements for Scientific Research       August 1987
  173.  
  174.  
  175.       Remote Job Entry
  176.  
  177.          The ability to submit batch jobs for processing to remote hosts
  178.          and receive output.
  179.  
  180.          Applications which need support in the near term but are NOT
  181.          extensions of currently supported applications include:
  182.  
  183.       Remote Instrument Control
  184.  
  185.          This normally presumes to have a human in the "control loop".
  186.          This condition relaxes the requirements on the (inter)network
  187.          somewhat as to response times and reliability.  Timing would be
  188.          presumed to be commensurate with human reactions and
  189.          reliability would not be as stringent as that required for
  190.          completely automatic control.
  191.  
  192.       Remote Data Acquisition
  193.  
  194.          This supports the collection of experimental data where the
  195.          experiment is remotely located from the collection center.
  196.          This requirement can only be satisfied when the bandwidth,
  197.          reliability, and predictability of network response are
  198.          sufficient.  This cannot be supported in the general sense
  199.          because of the enormous bandwidth, very high reliability,
  200.          and/or guaranteed short response time required for many
  201.          experiments.
  202.  
  203.    These last two requirements are especially crucial when one considers
  204.    remote experimentation such as will be performed on the Space
  205.    Station.
  206.  
  207. Capabilities
  208.  
  209.    The above applications could be best supported on a network with
  210.    infinite bandwidth, zero delay, and perfect reliability.
  211.    Unfortunately, even currently feasible approximations to these levels
  212.    of capabilities can be very expensive. Therefore, it can be expected
  213.    that compromises will be made for each capability and between them,
  214.    with different balances struck between different networks.  Because
  215.    of this, the user must be given an opportunity to declare which
  216.    capability or capabilities is/are of most interest-most likely
  217.    through a "type-of-service" required declaration.  Some examples of
  218.    possible trade-offs: File Transport Normally requires high
  219.    reliability primarily and high bandwidth secondarily. Delay is not as
  220.    important.
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Leiner                                                          [Page 4]
  227.  
  228. RFC 1017          Requirements for Scientific Research       August 1987
  229.  
  230.  
  231.       Bulk Transport
  232.  
  233.          Some applications such as digitized video might require high
  234.          bandwidth as the most important capability.  Depending on the
  235.          application, delay would be second, and reliability of lesser
  236.          importance.  Image transfers of scientific data sometimes will
  237.          invert the latter two requirements.
  238.  
  239.       Interactive Traffic
  240.  
  241.          This normally requires low delay as a primary consideration.
  242.          Reliability may be secondary depending on the application.
  243.          Bandwidth would usually be of least importance.
  244.  
  245. Standards
  246.  
  247.     The use of standards in networking is directed toward
  248.     interoperability and availability of commercial equipment.  However,
  249.     as stated earlier, full interoperability across the entire
  250.     scientific community is probably not a reasonable goal for
  251.     internetworking in the near term because of the protocol mix now
  252.     present.  That is not to say, though, that the use of standards
  253.     should not be pursued on the path to full user interoperability.
  254.     Standards, in the context of near term goal support, include:
  255.  
  256. Media Exchange Standards
  257.  
  258.    Would allow the interchange of equations, graphics, images, and data
  259.    bases as well as text.
  260.  
  261. Commercially Available Standards
  262.  
  263.    Plug compatible, commercially available standards will allow a degree
  264.    of interoperability prior to the widespread availability of the ISO
  265.    standard protocols.
  266.  
  267. Long Term Goals
  268.  
  269.    In the future, the internetwork should be transparent communications
  270.    between users and resources, and provide the additional network
  271.    services required to make use of that communications.  A user should
  272.    be able to access whatever resources are available just as if the
  273.    resource is in the office.  The same high level of service should
  274.    exist independent of which network one happens to be on.  In fact,
  275.    one should not even be able to tell that the network is there!
  276.  
  277.    It is also important that people be able to work effectively while at
  278.    home or when traveling.  Wherever one may happen to be, it should be
  279.  
  280.  
  281.  
  282. Leiner                                                          [Page 5]
  283.  
  284. RFC 1017          Requirements for Scientific Research       August 1987
  285.  
  286.  
  287.    possible to "plug into" the internetwork and read mail, access files,
  288.    control remote instruments, and have the same kind of environment one
  289.    is used to at the office.
  290.  
  291.    Services to locate required facilities and take advantage of them
  292.    must also be available on the network.  These range from the basic
  293.    "white" and "yellow" pages, providing network locations (addresses)
  294.    for users and capabilities, through to distributed data bases and
  295.    computing facilities.  Eventually, this conglomeration of computers,
  296.    workstations, networks, and other computing resources will become one
  297.    gigantic distributed "world computer" with a very large number of
  298.    processing nodes all over the world.
  299.  
  300. 2.  NETWORK CONNECTIVITY
  301.  
  302.    By network connectivity, we mean the ability to move packets from one
  303.    point to another.
  304.  
  305.    Note that an implicit assumption in this paper is that packet
  306.    switched networks are the preferred technology for providing a
  307.    scientific computer network.  This is due to the ability of such
  308.    networks to share the available link resources to provide
  309.    interconnection between numerous sites and their ability to
  310.    effectively handle the "bursty" computer communication requirement.
  311.  
  312.    Note that this need not mean functional interoperability, since the
  313.    endpoints may be using incompatible protocols.  Thus, in this
  314.    section, we will be addressing the use of shared links and
  315.    interconnected networks to provide a possible path.  In the next
  316.    section, the exploitation of these paths to achieve functional
  317.    connectivity will be addressed.
  318.  
  319.    In this section, we discuss the need for providing these network
  320.    paths to a wide set of users and resources, and the characteristics
  321.    of those paths.  As in other sections, this discussion is broken into
  322.    two major categories.  The first category are those goals which we
  323.    believe to be achievable with currently available technology and
  324.    implementations.  The second category are those for which further
  325.    research is required.
  326.  
  327. Near Term Objectives
  328.  
  329.    Currently, there are a large number of networks serving the
  330.    scientific community, including Arpanet, MFEnet, SPAN, NASnet, and
  331.    the NSFnet backbone.  While there is some loose correlation between
  332.    the networks and the disciplines they serve, these networks are
  333.    organized more based on Federal funding.  Furthermore, while there is
  334.    significant interconnectivity between a number of the networks, there
  335.  
  336.  
  337.  
  338. Leiner                                                          [Page 6]
  339.  
  340. RFC 1017          Requirements for Scientific Research       August 1987
  341.  
  342.  
  343.    is considerable room for more sharing of these resources.
  344.  
  345.    In the near term, therefore, there are two major requirement areas;
  346.    providing for connectivity based on discipline and user community,
  347.    and providing for the effective use of adequate networking resources.
  348.  
  349. Discipline Connectivity
  350.  
  351.    Scientists in a particular community/discipline need to have access
  352.    to many common resources as well as communicate with each other.  For
  353.    example, the quantum physics research community obtains funding from
  354.    a number of Federal sources, but carries out its research within the
  355.    context of a scientific discourse.  Furthermore, this discourse often
  356.    overlaps several disciplines.  Because networks are generally
  357.    oriented based on the source of funding, this required connectivity
  358.    has in the past been inhibited.  NSFnet is a major step towards
  359.    satisfying this requirement, because of its underlying philosophy of
  360.    acting as an interconnectivity network between supercomputer centers
  361.    and between state, regional, and therefore campus networks.  This
  362.    move towards a set of networks that are interconnected, at least at
  363.    the packet transport level, must be continued so that a scientist can
  364.    obtain connectivity between his/her local computing equipment and the
  365.    computing and other resources that are needed, independently of the
  366.    source of funds.
  367.  
  368.    Obviously, actual use of those resources will depend on obtaining
  369.    access permission from the appropriate controlling organization.  For
  370.    example, use of a supercomputer will require permission and some
  371.    allocation of computing resources.  The lack of network access should
  372.    not, however, be the limiting factor for resource utilization.
  373.  
  374. Communication Resource Sharing
  375.  
  376.    The scientific community is always going to suffer from a lack of
  377.    adequate communication bandwidth and connections.  There are
  378.    requirements (e.g. graphic animation from supercomputers) that
  379.    stretch the capabilities of even the most advanced long-haul
  380.    networks.  In addition, as more and more scientists require
  381.    connection into networks, the ability to provide those connections on
  382.    a network-centric basis will become more and more difficult.
  383.  
  384.    However, the communication links (e.g. leased lines and satellite
  385.    channels) providing the underlying topology of the various networks
  386.    span in aggregate a very broad range of the scientific community
  387.    sites.  If, therefore, the networks could share these links in an
  388.    effective manner, two objectives could be achieved:
  389.  
  390.       The need to add links just to support a particular network
  391.  
  392.  
  393.  
  394. Leiner                                                          [Page 7]
  395.  
  396. RFC 1017          Requirements for Scientific Research       August 1987
  397.  
  398.  
  399.       topology change would be decreased, and
  400.  
  401.       New user sites could be connected more readily.
  402.  
  403.    Existing technology (namely the DARPA-developed gateway system based
  404.    on the Internet Protocol, IP) provides an effective method for
  405.    accomplishing this sharing.  By using IP gateways to connect the
  406.    various networks, and by arranging for suitable cost-sharing, the
  407.    underlying connectivity would be greatly expanded and both of the
  408.    above objectives achieved.
  409.  
  410. Expansion of Physical Structure
  411.  
  412.    Unfortunately, the mere interconnectivity of the various networks
  413.    does not increase the bandwidth available.  While it may allow for
  414.    more effective use of that available bandwidth, a sufficient number
  415.    of links with adequate bandwidth must be provided to avoid network
  416.    congestion.  This problem has already occurred in the Arpanet, where
  417.    the expansion of the use of the network without a concurrent
  418.    expansion in the trunking and topology has resulted in congestion and
  419.    consequent degradation in performance.
  420.  
  421.    Thus, it is necessary to augment the current physical structure
  422.    (links and switches) both by increasing the bandwidth of the current
  423.    configuration and by adding additional links and switches where
  424.    appropriate.
  425.  
  426. Network Engineering
  427.  
  428.    One of the major deficiencies in the current system of networks is
  429.    the lack of overall engineering.  While each of the various networks
  430.    generally is well supported, there is woefully little engineering of
  431.    the overall system.  As the networks are interconnected into a larger
  432.    system, this need will become more severe.  Examples of the areas
  433.    where engineering is needed are:
  434.  
  435.    Topology engineering-deciding where links and switches should be
  436.    installed or upgraded.  If the interconnection of the networks is
  437.    achieved, this will often involve a decision as to which networks
  438.    need to be upgraded as well as deciding where in the network those
  439.    upgrades should take place.
  440.  
  441.    Connection Engineering-when a user site desires to be connected,
  442.    deciding which node of which network is the best for that site,
  443.    considering such issues as existing node locations, available
  444.    bandwidth, and expected traffic patterns to/from that site.
  445.  
  446.    Operations and Maintenance-monitoring the operation of the overall
  447.  
  448.  
  449.  
  450. Leiner                                                          [Page 8]
  451.  
  452. RFC 1017          Requirements for Scientific Research       August 1987
  453.  
  454.  
  455.    system and identifying corrective actions when failures occur.
  456.  
  457. Support of Different Types of Service
  458.  
  459.    Several different end user applications are currently in place, and
  460.    these put different demands on the underlying structure.  For
  461.    example, interactive remote login requires low delay, while file
  462.    transfer requires high bandwidth.  It is important in the
  463.    installation of additional links and switches that care be given to
  464.    providing a mix of link characteristics.  For example, high bandwidth
  465.    satellite channels may be appropriate to support broadcast
  466.    applications or graphics, while low delay will be required to support
  467.    interactive applications.
  468.  
  469. Future Goals
  470.  
  471.    Significant expansion of the underlying transport mechanisms will be
  472.    required to support future scientific networking.  These expansions
  473.    will be both in size and performance.
  474.  
  475. Bandwidth
  476.  
  477.    Bandwidth requirements are being driven higher by advances in
  478.    computer technology as well as the proliferation of that technology.
  479.    As high performance graphics workstations work cooperatively with
  480.    supercomputers, and as real-time remote robotics and experimental
  481.    control become a reality, the bandwidth requirements will continue to
  482.    grow.  In addition, as the number of sites on the networks increase,
  483.    so will the aggregate bandwidth requirement.  However, at the same
  484.    time, the underlying bandwidth capabilities are also increasing.
  485.    Satellite bandwidths of tens of megabits are available, and fiber
  486.    optics technologies are providing extremely high bandwidths (in the
  487.    range of gigabits).  It is therefore essential that the underlying
  488.    connectivity take advantage of these advances in communications to
  489.    increase the available end-to-end bandwidth.
  490.  
  491. Expressway Routing
  492.  
  493.    As higher levels of internet connectivity occur there will be a new
  494.    set of problems related to lowest hop count and lowest delay routing
  495.    metrics. The assumed internet connectivity can easily present
  496.    situations where the highest speed, lowest delay route between two
  497.    nodes on the same net is via a route on another network.  Consider
  498.    two sites one either end of the country, but both on the same
  499.    multipoint internet, where their network also is gatewayed to some
  500.    other network with high speed transcontinental links.  The routing
  501.    algorithms must be able to handle these situations gracefully, and
  502.    they become of increased importance in handling global type-of-
  503.  
  504.  
  505.  
  506. Leiner                                                          [Page 9]
  507.  
  508. RFC 1017          Requirements for Scientific Research       August 1987
  509.  
  510.  
  511.    service routing.
  512.  
  513. 3.  NETWORK SPECIFICATIONS
  514.  
  515.     To achieve the end-to-end user functions discussed in section 2, it
  516.     is not adequate to simply provide the underlying connectivity
  517.     described in the previous section.  The network must provide a
  518.     certain set of capabilities on an end-to-end basis.  In this
  519.     section, we discuss the specifications on the network that are
  520.     required.
  521.  
  522. Near Term Specifications
  523.  
  524.    In the near term, the requirements on the networks are two-fold.
  525.    First is to provide those functions that will permit full
  526.    interoperability, and second the internetwork must address the
  527.    additional requirements that arise in the connection of networks,
  528.    users, and resources.
  529.  
  530. Interoperability
  531.  
  532.    A first-order requirement for scientific computer networks (and
  533.    computer networks in general) is that they be interoperable with each
  534.    other, as discussed in the above section on connectivity.  A first
  535.    step to accomplish this is to use IP.  The use of IP will allow
  536.    individual networks built by differing agencies to combine resources
  537.    and minimize cost by avoiding the needless duplication of network
  538.    resources and their management.  However, use of IP does not provide
  539.    end-to-end interoperability.  There must also be compatibility of
  540.    higher level functions and protocols.  At a minimum, while commonly
  541.    agreed upon standards (such as the ISO developments) are proceeding,
  542.    methods for interoperability between different protocol suites must
  543.    be developed.  This would provide interoperability of certain
  544.    functions, such as file transfer, electronic mail and remote login.
  545.    The emphasis, however, should be on developing agreement within the
  546.    scientific community on use of a standard set of protocols.
  547.  
  548. Access Control
  549.  
  550.    The design of the network should include adequate methods for
  551.    controlling access to the network by unauthorized personnel.  This
  552.    especially includes access to network capabilities that are reachable
  553.    via the commercial phone network and public data nets.  For example,
  554.    terminal servers that allow users to dial up via commercial phone
  555.    lines should have adequate authentication mechanisms in place to
  556.    prevent access by unauthorized individuals.  However, it should be
  557.    noted that most hosts that are reachable via such networks are also
  558.    reachable via other "non-network" means, such as directly dialing
  559.  
  560.  
  561.  
  562. Leiner                                                         [Page 10]
  563.  
  564. RFC 1017          Requirements for Scientific Research       August 1987
  565.  
  566.  
  567.    over commercial phone lines.  The purpose of network access control
  568.    is not to insure isolation of hosts from unauthorized users, and
  569.    hosts should not expect the network itself to protect them from
  570.    "hackers".
  571.  
  572. Privacy
  573.  
  574.    The network should provide protection of data that traverses it in a
  575.    way that is commensurate with the sensitivity of that data.  It is
  576.    judged that the scientific requirements for privacy of data traveling
  577.    on networks does not warrant a large expenditure of resources in this
  578.    area.  However, nothing in the network design should preclude the use
  579.    of link level or end-to-end encryption, or other such methods that
  580.    can be added at a later time.  An example of this kind of capability
  581.    would be use of KG-84A link encryptors on MILNET or the Fig Leaf
  582.    DES-based end-to-end encryption box developed by DARPA.
  583.  
  584. Accounting
  585.  
  586.    The network should provide adequate accounting procedures to track
  587.    the consumption of network resources.  Accounting of network
  588.    resources is also important for the management of the network, and
  589.    particularly the management of interconnections with other networks.
  590.    Proper use of the accounting database should allow network management
  591.    personnel to determine the "flows" of data on the network, and the
  592.    identification of bottlenecks in network resources.  This capability
  593.    also has secondary value in tracking down intrusions of the network,
  594.    and to provide an audit trail if malicious abuse should occur.  In
  595.    addition, accounting of higher level network services (such as
  596.    terminal serving) should be kept track of for the same reasons.
  597.  
  598. Type of Service Routing
  599.  
  600.    Type of service routing is necessary since not all elements of
  601.    network activity require the same resources, and the opportunities
  602.    for minimizing use of costly network resources are large.  For
  603.    example, interactive traffic such as remote login requires low delay
  604.    so the network will not be a bottleneck to the user attempting to do
  605.    work.  Yet the bandwidth of interactive traffic can be quite small
  606.    compared to the requirements for file transfer and mail service which
  607.    are not response time critical.  Without type of service routing,
  608.    network resources must sized according to the largest user, and have
  609.    characteristics that are pleasing to the most finicky user.  This has
  610.    major cost implications for the network design, as high-delay links,
  611.    such as satellite links, cannot be used for interactive traffic
  612.    despite the significant cost savings they represent over terrestrial
  613.    links.  With type of service routing in place in the network
  614.    gateways, and proper software in the hosts to make use of such
  615.  
  616.  
  617.  
  618. Leiner                                                         [Page 11]
  619.  
  620. RFC 1017          Requirements for Scientific Research       August 1987
  621.  
  622.  
  623.    capabilities, overall network performance can be enhanced, and
  624.    sizable cost savings realized.  Since the IP protocol already has
  625.    provisions for such routing, such changes to existing implementations
  626.    does not require a major change in the underlying protocol
  627.    implementations.
  628.  
  629. Administration of Address Space
  630.  
  631.    Local administration of network address space is essential to provide
  632.    for prompt addition of hosts to the network, and to minimize the load
  633.    on backbone network administrators.  Further, a distributed name to
  634.    address translation service also has similar advantages.  The DARPA
  635.    Name Domain system currently in use on the Internet is a suitable
  636.    implementation of such a name to address translation system.
  637.  
  638. Remote Procedure Call Libraries
  639.  
  640.    In order to provide a standard library interface so that distributed
  641.    network utilities can easily communicate with each other in a
  642.    standard way, a standard Remote Procedure Call (RPC) library must be
  643.    deployed.  The computer industry has lead the research community in
  644.    developing RPC implementations, and current implementations tend to
  645.    be compatible within the same type of operating system, but not
  646.    across operating systems.  Nonetheless, a portable RPC implementation
  647.    that can be standardized can provide a substantial boost in present
  648.    capability to write operating system independent network utilities.
  649.    If a new RPC mechanism is to be designed from scratch, then it must
  650.    have enough capabilities to lure implementors away from current
  651.    standards.  Otherwise, modification of an existing standard that is
  652.    close to the mark in capabilities seems to be in order, with the
  653.    cooperation of vendors in the field to assure implementations will
  654.    exist for all major operating systems in use on the network.
  655.  
  656. Remote Job Entry (RJE)
  657.  
  658.    The capabilities of standard network RJE implementations are
  659.    inadequate, and are implemented prolifically among major operating
  660.    systems.  While the notion of RJE evokes memories of dated
  661.    technologies such as punch cards, the concept is still valid, and is
  662.    favored as a means of interaction with supercomputers by science
  663.    users.  All major supercomputer manufacturers support RJE access in
  664.    their operating systems, but many do not generalize well into the
  665.    Internet domain.  That is, a RJE standard that is designed for 2400
  666.    baud modem access from a card reader may not be easily modifiable for
  667.    use on the Internet.  Nonetheless, the capability for a network user
  668.    to submit a job from a host and have its output delivered on a
  669.    printer attached to a different host would be welcomed by most
  670.    science users.  Further, having this capability interoperate with
  671.  
  672.  
  673.  
  674. Leiner                                                         [Page 12]
  675.  
  676. RFC 1017          Requirements for Scientific Research       August 1987
  677.  
  678.  
  679.    existing RJE packages would add a large amount of flexibility to the
  680.    whole system.
  681.  
  682. Multiple Virtual Connections
  683.  
  684.    The capability to have multiple network connections open from a
  685.    user's workstation to remote network hosts is an invaluable tool that
  686.    greatly increases user productivity.  The network design should not
  687.    place limits (procedural or otherwise) on this capability.
  688.  
  689. Network Operation and Management Tools
  690.  
  691.    The present state of internet technology requires the use of
  692.    personnel who are, in the vernacular of the trade, called network
  693.    "wizards," for the proper operation and management of networks.
  694.    These people are a scarce resource to begin with, and squandering
  695.    them on day to day operational issues detracts from progress in the
  696.    more developmental areas of networking.  The cause of this problem is
  697.    that a good part of the knowledge for operating and managing a
  698.    network has never been written down in any sort of concise fashion,
  699.    and the reason for that is because networks of this type in the past
  700.    were primarily used as a research tool, not as an operational
  701.    resource.  While the usage of these networks has changed, the
  702.    technology has not adjusted to the new reality that a wizard may not
  703.    be nearby when a problem arises.  To insure that the network can
  704.    flexibly expand in the future, new tools must be developed that allow
  705.    non-wizards to monitor network performance, determine trouble spots,
  706.    and implement repairs or 'work-arounds'.
  707.  
  708. Future Goals
  709.  
  710.    The networks of the future must be able to support transparent access
  711.    to distributed resources of a variety of different kinds.  These
  712.    resources will include supercomputer facilities, remote observing
  713.    facilities, distributed archives and databases, and other network
  714.    services.  Access to these resources is to be made widely available
  715.    to scientists, other researchers, and support personnel located at
  716.    remote sites over a variety of internetted connections.  Different
  717.    modes of access must be supported that are consonant with the sorts
  718.    of resources that are being accessed, the data bandwidths required
  719.    and the type of interaction demanded by the application.
  720.  
  721.    Network protocol enhancements will be required to support this
  722.    expansion in functionality; mere increases in bandwidth are not
  723.    sufficient.  The number of end nodes to be connected is in the
  724.    hundreds of thousands, driven by increasing use of microprocessors
  725.    and workstations throughout the community.  Fundamentally different
  726.    sorts of services from those now offered are anticipated, and dynamic
  727.  
  728.  
  729.  
  730. Leiner                                                         [Page 13]
  731.  
  732. RFC 1017          Requirements for Scientific Research       August 1987
  733.  
  734.  
  735.    bandwidth selection and allocation will be required to support the
  736.    different access modes.  Large-scale internet connections among
  737.    several agency size internets will require new approaches to routing
  738.    and naming paradigms.  All of this must be planned so as to
  739.    facilitate transition to the ISO/OSI standards as these mature and
  740.    robust implementations are placed in service and tuned for
  741.    performance.
  742.  
  743.    Several specific areas are identified as being of critical importance
  744.    in support of future network requirements, listed in no particular
  745.    order:
  746.  
  747.       Standards and Interface Abstractions
  748.  
  749.          As more and different services are made available on these
  750.          various networks it will become increasingly important to
  751.          identify interface standards and suitable application
  752.          abstractions to support remote resource access.  These
  753.          abstractions may be applicable at several levels in the
  754.          protocol hierarchy and can serve to enhance both applications
  755.          functionality and portability.  Examples are transport or
  756.          connection layer abstractions that support applications
  757.          independence from lower level network realizations or interface
  758.          abstractions that provide a data description language that can
  759.          handle a full range of abstract data type definitions.
  760.          Applications or connection level abstractions can provide means
  761.          of bridging across different protocol suites as well as helping
  762.          with protocol transition.
  763.  
  764.       OSI Transition and Enhancements
  765.  
  766.          Further evolution of the OSI network protocols and realization
  767.          of large-scale networks so that some of the real protocol and
  768.          tuning issues can be dealt with must be anticipated.  It is
  769.          only when such networks have been created that these issues can
  770.          be approached and resolved.  Type-of-service and Expressway
  771.          routing and related routing issues must be resolved before a
  772.          real transition can be contemplated.  Using the interface
  773.          abstraction approach just described will allow definition now
  774.          of applications that can transition as the lower layer networks
  775.          are implemented.  Applications gateways and relay functions
  776.          will be a part of this transition strategy, along with dual
  777.          mode gateways and protocol translation layers.
  778.  
  779.       Processor Count Expansion
  780.  
  781.          Increases in the numbers of nodes and host sites and the
  782.          expected growth in use of micro-computers, super-micro
  783.  
  784.  
  785.  
  786. Leiner                                                         [Page 14]
  787.  
  788. RFC 1017          Requirements for Scientific Research       August 1987
  789.  
  790.  
  791.          workstations, and other modest cost but high power computing
  792.          solutions will drive the development of different network and
  793.          interconnect strategies as well as the infrastructure for
  794.          managing this increased name space.  Hierarchical name
  795.          management (as in domain based naming) and suitable transport
  796.          layer realizations will be required to build networks that are
  797.          robust and functional in the face of the anticipated
  798.          expansions.
  799.  
  800.       Dynamic Binding of Names to Addresses
  801.  
  802.          Increased processor counts and increased usage of portable
  803.          units, mobile units and lap-top micros will make dynamic
  804.          management of the name/address space a must.  Units must have
  805.          fixed designations that can be re-bound to physical addresses
  806.          as required or expedient.
  807.  
  808. 4.  USER SERVICES
  809.  
  810.    The user services of the network are a key aspect of making the
  811.    network directly useful to the scientist.  Without the right user
  812.    services, network users separate into artificial subclasses based on
  813.    their degree of sophistication in acquiring skill in the use of the
  814.    network.  Flexible information dissemination equalizes the
  815.    effectiveness of the network for different kinds of users.
  816.  
  817. Near Term Requirements
  818.  
  819.    In the near term, the focus is on providing the services that allow
  820.    users to take advantage of the functions that the interconnected
  821.    network provides.
  822.  
  823. Directory services
  824.  
  825.    Much of the information necessary in the use of the network is for
  826.    directory purposes.  The user needs to access resources available on
  827.    the network, and needs to obtain a name or address.
  828.  
  829. White Pages
  830.  
  831.    The network needs to provide mechanisms for looking up names and
  832.    addresses of people and hosts on the network.  Flexible searches
  833.    should be possible on multiple aspects of the directory listing.
  834.    Some of these services are normally transparent to the user/host name
  835.    to address translation for example.
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Leiner                                                         [Page 15]
  843.  
  844. RFC 1017          Requirements for Scientific Research       August 1987
  845.  
  846.  
  847. Yellow Pages
  848.  
  849.    Other kinds of information lookup are based on cataloging and
  850.    classification of information about resources on the networks.
  851.  
  852. Information Sharing Services
  853.  
  854.       Bulletin Boards
  855.  
  856.          The service of the electronic bulletin board is the one-to-many
  857.          analog of the one-to-one service of electronic mail.  A
  858.          bulletin board provides a forum for discussion and interchange
  859.          of information.  Accessibility is network-wide depending on the
  860.          definition of the particular bulletin board.  Currently the
  861.          SMTP and UUCP protocols are used in the transport of postings
  862.          for many bulletin boards, but any similar electronic mail
  863.          transport can be substituted without affecting the underlying
  864.          concept.  An effectively open-ended recipient list is specified
  865.          as the recipient of a message, which then constitutes a
  866.          bulletin board posting.  A convention exists as to what
  867.          transport protocols are utilized for a particular set of
  868.          bulletin boards.  The user agent used to access the Bulletin
  869.          Board may vary from host to host.  Some number of host
  870.          resources on the network provide the service of progressively
  871.          expanding the symbolic mail address of the Bulletin Board into
  872.          its constituent parts, as well as relaying postings as a
  873.          service to the network.  Associated with this service is the
  874.          maintenance of the lists used in distributing the postings.
  875.          This maintenance includes responding to requests from Bulletin
  876.          Board readers and host Bulletin Board managers, as well as
  877.          drawing the appropriate conclusions from recurring
  878.          automatically generated or error messages in response to
  879.          distribution attempts.
  880.  
  881.       Community Archiving
  882.  
  883.          Much information can be shared over the network.  At some point
  884.          each particular information item reaches the stage where it is
  885.          no longer appropriately kept online and accessible.  When
  886.          moving a file of information to offline storage, a network can
  887.          provide its hosts a considerable economy if information of
  888.          interest to several of them need only be stored offline once.
  889.          Procedures then exist for querying and retrieving from the set
  890.          of offline stored files.
  891.  
  892.       Shared/distributed file system
  893.  
  894.          It should be possible for a user on the network to look at a
  895.  
  896.  
  897.  
  898. Leiner                                                         [Page 16]
  899.  
  900. RFC 1017          Requirements for Scientific Research       August 1987
  901.  
  902.  
  903.          broadly defined collection of information on the network as one
  904.          useful whole.  To this end, standards for accessing files
  905.          remotely are necessary.  These standards should include means
  906.          for random access to remote files, similar to the generally
  907.          employed on a single computer system.
  908.  
  909.       Distributed Databases and Archives
  910.  
  911.          As more scientific disciplines computerize their data archives
  912.          and catalogs, mechanisms will have to be provided to support
  913.          distributed access to these resources.  Fundamentally new kins
  914.          of collaborative research will become possible when such
  915.          resources and access mechanisms are widely available.
  916.  
  917.       Resource Sharing Services
  918.  
  919.          In sharing the resources or services available on the network,
  920.          certain ancillary services are needed depending on the
  921.          resource.
  922.  
  923. Access Control
  924.  
  925.    Identification and authorization is needed for individuals, hosts or
  926.    subnetworks permitted to make use of a resource available via the
  927.    network.  There should be consistency of procedure for obtaining and
  928.    utilizing permission for use of shared resources.  The identification
  929.    scheme used for access to the network should be available for use by
  930.    resources as well.  In some cases, this will serve as sufficient
  931.    access control, and in other cases it will be a useful adjunct to
  932.    resource-specific controls.  The information on the current network
  933.    location of the user should be available along with information on
  934.    user identification to permit added flexibility for resources.  For
  935.    example, it should be possible to verify that an access attempt is
  936.    coming from within a state.  A state agency might then grant public
  937.    access to its services only for users within the state.  Attributes
  938.    of individuals should be codifiable within the access control
  939.    database, for example membership in a given professional society.
  940.  
  941. Privacy
  942.  
  943.    Users of a resource have a right to expect that they have control
  944.    over the release of the information they generate.  Resources should
  945.    allow classifying information according to degree of access, i.e.
  946.    none, access to read, access according to criteria specified in the
  947.    data itself, ability to change or add information.  The full range of
  948.    identification information described under access control should be
  949.    available to the user when specifying access.  Access could be
  950.    granted to all fellow members of a professional society, for example.
  951.  
  952.  
  953.  
  954. Leiner                                                         [Page 17]
  955.  
  956. RFC 1017          Requirements for Scientific Research       August 1987
  957.  
  958.  
  959. Accounting
  960.  
  961.    To permit auditing of usage, accounting information should be
  962.    provided for those resources for which it is deemed necessary.  This
  963.    would include identity of the user of the resource and the
  964.    corresponding volume of resource components.
  965.  
  966. Legalities of Interagency Research Internet
  967.  
  968.    To make the multiply-sponsored internetwork feasible, the federal
  969.    budget will have to recognize that some usage outside a particular
  970.    budget category may occur.  This will permit the cross-utilization of
  971.    agency funded resources.  For example, NSFnet researchers would be
  972.    able to access supercomputers over NASnet.  In return for this, the
  973.    total cost to the government will be significantly reduced because of
  974.    the benefits of sharing network and other resources, rather than
  975.    duplicating them.
  976.  
  977. Standards
  978.  
  979.    In order for the networking needs of scientific computing to be met,
  980.    new standards are going to evolve.  It is important that they be
  981.    tested under actual use conditions, and that feedback be used to
  982.    refine them.  Since the standards for scientific communication and
  983.    networking are to be experimented with, they are more dynamic than
  984.    those in other electronic communication fields.  It is critical that
  985.    the resources of the network be expended to promulgate experimental
  986.    standards and maximize the range of the community utilizing them.  To
  987.    this end, the sharing of results of the testing is important.
  988.  
  989. User-oriented Documentation
  990.  
  991.    The functionality of the network should be available widely without
  992.    the costly need to refer requests to experts for formulation.  A
  993.    basic information facility in the network should therefore be
  994.    developed.  The network should be self-documenting via online help
  995.    files, interactive tutorials, and good design.  In addition, concise,
  996.    well-indexed and complete printed documentation should be available.
  997.  
  998. Future Goals
  999.  
  1000.    The goal for the future should be to provide the advanced user
  1001.    services that allow full advantage to be taken of the interconnection
  1002.    of users, computing resources, data bases, and experimental
  1003.    facilities.  One major goal would be the creation of a national
  1004.    knowledge bank.  Such a knowledge bank would capture and organize
  1005.    computer-based knowledge in various scientific fields that is
  1006.    currently available only in written/printed form, or in the minds of
  1007.  
  1008.  
  1009.  
  1010. Leiner                                                         [Page 18]
  1011.  
  1012. RFC 1017          Requirements for Scientific Research       August 1987
  1013.  
  1014.  
  1015.    experts or experienced workers in the field.  This knowledge would be
  1016.    stored in knowledge banks which will be accessible over the network
  1017.    to individual researchers and their programs.  The result will be a
  1018.    codification of scientific understanding and technical know-how in a
  1019.    series of knowledge based systems which would become increasingly
  1020.    capable over time.
  1021.  
  1022. CONCLUSION
  1023.  
  1024.    In this paper, we have tried to describe the functions required of
  1025.    the interconnected national network to support scientific research.
  1026.    These functions range from basic connectivity through to the
  1027.    provision for powerful distributed user services.
  1028.  
  1029.    Many of the goals described in this paper are achievable with current
  1030.    technology.  They require coordination of the various networking
  1031.    activities, agreement to share costs and technologies, and agreement
  1032.    to use common protocols and standards in the provision of those
  1033.    functions.  Other goals require further research, where the
  1034.    coordination of the efforts and sharing of results will be key to
  1035.    making those results available to the scientific user.
  1036.  
  1037.    For these reasons, we welcome the initiative represented by this
  1038.    workshop to have the government agencies join forces in providing the
  1039.    best network facilities possible in support of scientific research.
  1040.  
  1041. APPENDIX
  1042.  
  1043.                 Internet Task Force on Scientific Computing
  1044.  
  1045.  
  1046.              Rick Adrion     University of Massachusetts
  1047.              Ron Bailey      NASA Ames Research Center
  1048.              Rick Bogart     Stanford University
  1049.              Bob Brown       RIACS
  1050.              Dave Farber     University of Delaware
  1051.              Alan Katz       USC Information Science Institute
  1052.              Jim Leighton    Lawrence Livermore Laboratories
  1053.              Keith Lantz     Stanford University
  1054.              Barry Leiner    (chair) RIACS
  1055.              Milo Medin      NASA Ames Research Center
  1056.              Mike Muuss      US Army Ballistics Research Laboratory
  1057.              Harvey Newman   California Institute of Technology
  1058.              David Roode     Intellicorp
  1059.              Ari Ollikainen  General Electric
  1060.              Peter Shames    Space Telescope Science Institute
  1061.              Phil Scherrer   Stanford University
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Leiner                                                         [Page 19]
  1067.